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PROCEDE DE VERIFICATION DE TRANSFORMATEURS DE CODES POUR 
UN SYSTEME EMBARQUE, NOTAMMENT SUR UNE CARTE A PUCE 

L'invention concerns un procede de verification de transformateurs de 
codes pour un systeme embarque. 

L'invention concerns aussi ['application d'un tel procede a un 
transformateur pour generer un code destine a une carte a puce. 

Dans le cadre de invention, le terme "systeme embarque" doit etre 
considere dans son acception la plus generale. II concerne notamment des 
systemes destines a une carte a puce, ce qui constitue I'application preferee 
de l'invention, mais egalement tout systeme destine a un dispositif portable ou 
mobile comportant des moyens propres de traitement de donnees informatises, 
que Ton appellera ci-apres "ressources de traitement". 

Les systemes embarques modernes sont munis de ressources de 
traitement des donnees permettent de remplir des fonctions de plus en plus 
complexes et de plus en plus nombreuses. Cependant, malgre la mise sur le 
marche de technologies et de composants de plus en plus performants, une 
caracteristique distinctive des systemes embarques, par rapport a des 
systemes informatiques conventionnels (micro-ordinateur, station de travail, 
etc.), concerne les limitations qu'ils imposent en matiere de ressources (taille 
memoire et puissance des microprocesseurs notamment). Pour satisfaire ces 
contraintes, il est necessaire de transformer le code destine a etre execute sur 
un systeme embarque. Les transformations ont pour but de produire un code 
plus efficace et plus econome en ressources. 

Pour fixer les Idees, et a titre d'exemple non limitatif de code, on 
considerera dans ce qui suit un programme ecrit dans la machine virtuelle du 
langage "JAVA" (marque deposes par SUN MICROSYSTEMS) qui presente 
I'interet de pouvoir etre execute dans de nombreux environnements. Les 
domaines d'application de ce langage se sont en effet multiplies notamment 
avec le developpement important du reseau Internet. De nombreuses 
applications logicielles de petite taille, dites "applets", sont ecrites dans ce 
langage et exscutables par un navigatsur de typs "WEB" 
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On se placera egalement dans le cadre de Tapplication preferee de 
rinvention. a savoir I'execution d'un code de ce type par les ressources 
informatiques propres d'une carte a puce. Comme il a ete rappele ci-dessus, 
malgre des progres technologiques importants, la capacite memoire de la carte 

5 a puce, ainsi que la puissance du microprocesseur qui Tequipe restent 
relativement iimites. II est egalement important que le code soit resident dans 
la carte a puce, car les transmissions entre celle-ci et un terminal hote, quel 
qu'il soit, s'effectuent a basse vitesse. Les standards actuels ne prevoient que 
des transmissions de type serie. Le besoin se fait done sentir de disposer d'un 

10 code que Ton pourrait qualifier "d'allege", en tout cas optimise pour cet usage. 
Pour ce faire, 11 a ete propose d'utiliser un langage derive de "JAVA", se 
presentant sous la forme d'une restriction de ce langage, a savoir le langage 
"JAVA CARD" " (marque deposee egalement par SUN MICROSYSTEMS). 

Una complication supplementaire vient du fait que les systemes em- 

15 barques sont generalement utilises dans des environnements qui requierent 
les plus hautes garanties en matiere, a la fois de fiabilite et de securite. On 
peut citer a titre d'exemple les nouvelles versions de cartes a puce sur 
iesqueiies on souhaite installer des applications logicielles multiples qui 
doivent cooperer harmonieusement sans reveler d'informations confidentielles. 

20 En effet, a priori, ces multiples applications peuvent concerner des utilisateurs 
distincts. Malgre la cooperation precitee, on doit conserver un cloisonnement 
rigoureux, pour que les informations concernant un utilisateur donne restent 
confidentielles, pour le moins ne puissent pas etre mises a la disposition d'un 
utilisateur non habilite a les connaltre (lecture) et/ou a les manipuler (ecriture 

25 et operations connexes : effacement, modification). En dehors de I'aspect 
"confidentialite", d'autres exigences sont a prendre en compte, notamment 
I'exigence dite "d'integrite" : pertes de donnees, modifications non conformes, 
etc. 

Si on considere le code "source", dans le sens de "code initial", tel que 
30 par exemple le "byte code" du langage "JAVA" precite, ce dernier presente 
toutes les garanties necessaires et remplit les exigences precitees, le "byte 
code" etant un programme ecrit dans la machine virtuelle du langage "JAVA". 
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En effet, de nombreux tests ont pu etre effectues, ce pendant de longues 
periodes de temps. 

Le code dit "transforme" est obtenu a partir du "code source" a I'aide 
d'un transformateur de code, generalement exterieur au systeme embarque, 
5 mais qui peut egalement etre resident dans celui-ci. II est done necessaire de 
montrer I'equivalence entre le code source et le code transforme. 

Cela peut s'effectuer en garantissant que les transformations 
effectuees sur le code ne changent en rien son comportement (d'un point de 
vue externe) et n'introduisent pas de failles de securite. En d'autres termes, le 
10 code initial (avant transformation) doit etre d'un point de vue logique equivalent 
au code resultant (apres transformation). 

II est particulierement difficile de garantir cette propriete en general, 
car les transformations ont un effet global sur le code et sur les representations 
des donnees qu'il manipule. De fafon pratique, la complexite impliquee par 
IS cette operation ne permet pas une mise en ceuvre dans des conditions 
economiques et/ou technologiques realistes. En outre, on doit bien comprendre 
que de tels besoins ne sont apparus que tres recemment, notamment en 
conjonction avec le developpement des technologies precitees de cartes a 
puce multi-applications et/ou multi-utilisateurs. 
20 L'invention vise a repondre a ces besoins, sans necessiter des 

procedures extremement longues et couteuses. 

Le procede seion Tinvention permet de verifier de maniere 
systematique et modulaire la correction des transformations de codes. 

Dans le cadre de l'invention, deux formalismes, bien connus en soi, 
25 seront utilises de fa^on essentielle : les semantiques operationnelles et les 
relations logiques. Pour une description plus detaillee de ces formalismes, on 
se reportera avec profit, pour le premier, au livre de : H. R. Nielson, et F. 
Nielson, intitule : '^Semantics with Applications: A formal Introduction". H//ley, 
1992, et, pour le second, au livre de J. Mitchell ; "Foundations for Programming 
30 Languages'', MIT Press, 1996. 

Seion une caracteristique essentielle de l'invention, le procede de 
verification des transformateurs de codes consiste a specifier le sens de deux 
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codes a Taide d'une machine virtuelle commune parametree par des fonctions 
que Ton appellera *fonctions auxiliaires". Las differences entre les deux codes 
sont exprimees et regroupees dans les fonctions auxiliaires precitees. Chaque 
fonction auxiliaire possede deux versions : une version dans le code source et 
5 une version dans le code transforme. Les premiers modules etant identiques, 
puisque communs aux deux codes, tl n'y a pas lieu de verifier s'ils sont 
equivalents- Pour montrer Tequivalence des deux codes, ii suffit done de 
montrer que les fonctions dites auxiliaires, considerees deux a deux, sont 
equivalentes. Ces deux sous-ensembles peuvent etre rendus beaucoup moins 

10 complexes que les deux ensembles representes par les deux codes, source et 
transforme, consideres dans leur integralite. II s*ensuit que, selon le precede 
de I'invention, la difficulte inherente au processus de verification est tres 
fortement reduite, et de fa^on correlative, ie processus de verification devient 
economiquement et technologiquement realisable. 

15 L'invention a done pour objet un procede de verification d'un 

transformateur de code dit source en un code dit transforme destine a un 
systeme embarque, lesdits codes source et transforme etant associes a des 
machines virtuelles, caractehse en ce quMI comprend au moins les etapes 
suivantes : 

20 - la determination, pour chacun desdits codes source et transforme, d'un 

premier sous-ensemble commun, constituent une machine virtuelle unique 

factorisant le comportement de ces deux codes ; 

la determination, pour chacun desdits codes source et transforme, d'un 

second sous-ensemble constitue d'une pluralite de fonctions dites 
25 auxiliaires, lesdites fonctions auxiliaires representant des differences 

residuelles entre lesdits codes source et transforme ; 

Tassociation par paire desdites fonctions auxiliaires, une premiere 

fonction auxiliaire de chaque paire appartenant audit second sous-ensembie 

associe audit code source et une seconde fonction auxiliaire de chaque 
30 paire appartenant audit second sous-ensemble associe audit code 

transforme ; 
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la verification d'une propriete de correspondance determinee entre 
lesdites fonctions auxiliaires de toutes lesdites paires ; et 

la verification que ladite transformation du code source en code 
transforme par ledit convertisseur respecte ladite propriete de 
5 correspondance determinee. 

L'invention a encore pour objet Tapplication d'un tel precede a un 
transformateur pour la generation d'un code destine a etre enregistre dans une 
carte a puce. 

L'invention va maintenant etre decrite de fapon plus detaillee en se 
10 referant aux dessins annexes, parmi iesquels : 

la figure 1 illustre schematiquement le processus de 
transformation d'un code source en un code transforme final ; 

les figures 2A et 2B illustrent schematiquement une des 
caracteristiques essentielles du precede selon l'invention ; et 
15 - la figure 3 illustre schematiquement Tapplication du precede selon 

l'invention a une carte a puce ; 

On va maintenant decrire de fagon detaillee le precede de verification 
de transformateurs de codes selon l'invention. 

La figure 1 illustre schematiquement le processus de transformation 

20 d'un code 1, que Ton appellera "cede source", dans le sens de code origine ou 
initial, en un code final 3, dit "code transforme", a I'aide d'un transformateur de 
code 2. Ce dernier ergane peut etre un moyen informatique ou une piece de 
logiciel specifique. De iagon habituelle, le code transforme est destine a etre 
resident dans le systeme embarque 4 (en trait plein). Le transformateur 2 peut 

25 egalement etre resident ou telecharge dans le systeme embarque : reference 4' 
(en traits pointilles). 

Apres chargement ou enregistrement dans le systeme embarque 4-4', 
le code transforme 3 permet I'execution d'une ou plusieurs taches en tant que 
de besoin, representees sous la reference unique 5, On suppose que le 

30 systeme embarque 4 dispose de ressources informatiques autonemes 
classiques (non representees). 
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A priori, la transformation de code est effectuee une fois pour toutes 
par un transfornnateur donne 2 ou dans de rares occasions : modification de 
version du code d'origine ou code source 1 , par exemple. 

II est done necessaire que Ton puisse etablir la preuve formelle que le 
5 code transforme 3 est equivalent au code source 1. Ce processus permet de 
verifier si le transformateur 2 fonctionne de fagon correcte. 

Cependant, comme 11 a ete rappele,- si on considere, dans leur 
globalite, les deux ensembles formes par les codes, source et transforme, la 
theorie montre qu'une telle determination n'est generalement pas possible de 
10 fagon realiste. 

Une caracteristique essentielle du precede selon I'invention va 
consister a trouver pour chacun des deux codes deux sous-ensembles, que 
Ton appellera premier et second sous-ensembles. Selon une caracteristique 
importante du procede selon I'invention, les premiers sous-ensembles ferment 
15 une machine virtuelle commune aux deux codes, source et transforme. De ce 
fait, il n'est done pas necessaire de verifier Inequivalence des premiers sous- 
ensembles. 

Les seconds sous-ensembles, constitues des fonctiens auxiliaires. 
sent par centre distincts d'un code a Tautre. La determination de Tequivalence 
20 des codes, source et transforme, se reduit alors a la determination de 
I'equivalence de toutes les paires de fonctiens auxiliaires des seconds sous- 
ensembles. Or, la complexite residuelle des fonctiens auxiliaires peut etre tres 
reduite. II s'ensuit que la determination d'equivalence precitee devient possible. 
Les figures 2A et 2B illustrent tres schematiquement le procede selon 
25 rinvention. 

Comme le montre plus particulierement la figure 2A, les premiers 
sous-ensembles du code source 1 et du code transforme 3 ferment une 
machine virtuelle commune 13. Les seconds sous-ensembles, 10 et 30, sent 
constitues chacun par une serie de fenctions dites auxiliaires, dent 
30 I'equivalence devra etre verifiee. Ces fonctions auxiliaires, 10 et 30, 
parametrent la machine virtuelle commune 13. 
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Uequivalence des deux codes, source 1 et transforme 2, se reduit 
done a verifier Inequivalence des fonctions auxiliaires, 10 et 30, prises deux a 
deux, comme il te sera montre ci-apres en regard de la figure 2B. 

Les etapes du precede vont maintenant etre decrites de iagon plus 
5 detainee. 

Les codes source et transforme sont associes a des premiere et 
seconde machines dites virtueiles, respectivement. 

La premiere etape consiste en la definition d'une machine virtuelle (ou 
semantique operationnelle) unique permettant de factoriser le comportement 
10 du code source et du code transforme. Les differences entre les deux codes 
apparaissent alors a travers des fonctions auxiliaires qui seront interpretees ou 
mises en oeuvre differemment dans les deux codes. 

Une machine virtuelle peut se representer par un ensemble de regies 
de la forme : 

15 

premisse 1 


premisse n 


etat1[lnstruction1] etat2 (1 

Les premisses sont, soit des conditions d'application d'une regie, c'est- 
a-dire des expressions booleennes, soit des affectations a des variables 
utilisees pour exprimer un changement rfetat. Les premisses font appel a des 
fonctions auxiliaires pour extraire des informations de Tetat ou exprimer des 
conditions. Chaque regie indique comment I'etat de la machine evolue lorsque 
les premisses sont verifiees et instruction "Instructioni" est rencontree. On 
definit une ou plusieurs regies de cette forme pour chaque type d'instruction du 
code. 
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La seconde etape consists en la definition de types ou structures de 
donnees utilises dans les deux codes. On definit des types basiques comme, 
par exemple : 

5 Basique ::= Nat | Bool | Norn... (2), 

et des types construits comme, par exemple : 

Environnement ::= Nom ~> Valeur 
10 Instructions :: = Instructioni I lnstruction2 I ... (3), 

La troisieme etape consiste en T interpretation de types, references 6, 
utilises dans les machines virtuelles. Pour chaque type 0, on definit una 
interpretation pour le code source d^J^^et une interpretation pour le code 
15 transforms, ][0]^ , plus une relation Re entre les deux interpretations JJ.J^ et 
[[.Jj. . Ces relations, appelees relations logiques, respectent la structure des 
types. Pour des t^p^? -Simples b!!bs doiv^nt etre definies explicitement ; pour 
des types structures, elles sont deduites des types des composants de la 
structure. 

20 Par exemple, pour les paires : 

(a, b) R0ue2{B\ b') <=>aReia' Rezb' (4), 

relation dans laquelle 0\ e\ 60. sont des types et a, Jb, a* et b' des elements de 
25 type. 

II en est de meme pour les fonctions : 

fRei^ei f <=> Va, a', a Rei a' =>fa Reifa' (5). 

30 Les relations logiques doivent etre la relation "identite" pour les types 

observabies, c'est a dire des types pour lesquels on veut montrer que les deux 
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codes rendent le meme resultat. II s'agit habituellement de types imphmables 
et/ou affichables sur un ecran informatique. Cela peut etre des types basiques, 
mais egalement des types structures representant, par exemple, una pile ou 
des variables d'un programme donne. 
5 La quatrieme etape consiste en {'interpretation des fonctions 

auxiliaires utilisees dans les machines virtuelles. Pour chaque fonction 
auxiliaire f, on donne sa definition pour le code source, notee [[/]]^ , et sa 
definition pour le code transforms, notee [[/Uy, . 

La determination de Tequivalence consiste a montrer que les 
10 definitions des fonctions auxiliaires respectent les relations logiques. Plus 
precisement, pour chaque fonction auxiliaire f \ 6^ ff, or\ montre 

D/IL R^^' lf\ (6). 

IS II s'ensuit que les deux machines virtuelles sont en relation, c'est-a- 

dire que : 

^etat% Rtype-etat ^etat\ (7). 

20 Comme les relations sont I'identite pour les types observables, les 

codes source et transforme sont observationeliement identiques. 

La derniere etape consiste a montrer qu'il existe un transformateur r 
(figure 1 : 2) qui satisfait les relations logiques. Cela peut etre fait en verifiant 
qu'un transformateur donne r : S 7 satisfait la relation logique associee au 

25 type de son argument, avec S code source (figure 1 : 1 ) et T code transforme 
(figure 1 : 3). Pour ce faire il est necessaire qu'il obeisse a la relation suivante : 

\fx^e\ ,xRor(x) (8). 

30 II vient d*etre montre que les relations logiques specifient un ensemble 

de contraintes. On peut done en extraire un transformateur 2 correct par 
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construction, en appliquant des techniques de raffinement ou d'extraction, en 
faisant appel a un des assistants de preuve appropries.. 

Le procede selon I'lnvention presente done un avantage important car 
il permet une grande mecanisation du processus de verification, et surtout 
5 permet de le conduire a bien, car cette verification est menee sur des sous- 
ensembles moins complexes. 

Si la transformation du code source 1 peut se decrire comme une 
succession de transformations plus simples, cette methode peut s'appliquer 
pour montrer chaque transformation independamment. II s'ensuit qu'elle 

10 presente un grand avantage de modularite. 

La verification ne doit etre effectuee que sur les sous-ensembles de 
fonctions auxiliaires 10 et 30, comme illustre par la figure 2B, a I'aide d'un 
organe 6, materiel ou logiciel. On a suppose qu'il existe n fonctions auxiliaires, 
referencees 10a, 10^,, 10/, .... lO^r, 10„ et 20^, 20^,, 20,, ...20n-r, 20„, 

15 respectivement. Si I'organe 6 est materiel, il comporte autant de circuits 
verificateurs, 60a, 60^, 60/, 60n-h 60„ (representes arbitrairement sur la 
figure 2B par le symbole d'un comparateur), que de paires de fonctions 
auxiliaires a verifier, par exemple le circuit verificateur 60/ pour la paire de 
fonctions 10/ et 30/. La ou les sortie(s) de cet organe 6, sous la reference 

20 unique 61, indique(nt) que la relation logique entre toutes les paires possibles 
de fonctions auxiliaires correspondantes des codes source 1 et transforme 3 
est satisfaite. Cette serie d'operations est suffisante pour apporter la preuve 
formelle de Tequivalence des deux codes, dans leur globalite. 

II est a noter que le procede selon Tinvention est utilisable aussi bien, 

25 a posteriori, c'est-a-dire pour verifier un transformateur existant, qu'a priori, 
comme une aide au developpement d'un nouveau transformateur. Elle permet 
notamment, dans ce dernier cas, d'en determiner les caracteristiques, pour qu'il 
fonctionne correctement, en d'autres termes pour que le code transforme qui 
sera genere par ce transformateur a partir du code source satisfasse I'exigence 

30 d'equivalence precitee. 

On va maintenant se placer dans le cadre des cartes a puce. La 
figure 3 illustre schematiquement I'architecture d'une carte a puce, referencee 
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7. On n'a represente sur cette figure que les elements essentiels a la bonne 
comprehension du procede selon {'invention. 

La carte a puce 7 comprend notamment un organe d'entree-sortie 70 
permettant des communications avec le monde exterieur, un premier organe de 
5 memoire 71, fixe ou programmable (de type *'ROM'\ "PROM", "EPROM" ou 
"EEPROM"), et un organe de memoire vive 72. La carte a puce 7 comprend 
enfin un microprocesseur ou un microcontroleur 73 dialoguant par 
i'intermediaire de bus avec les autres composants de la carte a puce 7. 

L'architecture logicielle d'une telle carte a puce 7 obeit a la norme ISO 
10 7816-3, se traduisant par une couche protocolaire allant des couches les plus 
basses associees aux organes d'entree-sortie 70, jusqu'aux couches les plus 
hautes associees aux applications logicielles enregistrees dans la carte a 
puce 7. Ces normes prevoient que les transmissions s'effectuent en mode 
serie. 

15 Le code source 1, une fois transforme par le transformateur de code 2, 

est transmis a la carte a puce 7 pour y etre enregistre, generalement dans 
I'organe de memoire 71, fixe ou "semi-fixe", via I'organe d'entree-sortie 70. La 
ou les applications logicielles traitees par la carte a puce 7 peuvent etre 
enregistrees a demeure dans la carte a puce 7, c'est-a-dire dans I'organe de 

20 memoire 71, ou de fagon transitoire dans la memoire vive 72. Dans ce dernier 
cas les applications sont telechargees via I'organe d'entree-sortie 70. Dans 
I'exemple decrit, il a ete suppose que la carte a puce 7 est d'un type multi- 
applications, voire multi-utilisateurs. 11 a done ete egalement suppose que la 
carte a puce 7 traite m applications logicielles, A^ a Am, ecrites dans !e langage 

25 transforme 3. 

Un des langages couramment utilises pour les cartes a puce est, 
comme il a ete rappele, le langage "Java Card". II s'agit d'un tangage dedie a la 
programmation des cartes a puce, langage qui constitue une restriction du 
langage "Java". 

30 La carte 7 peut egalement stocker un convertisseur supplementaire 

effectuant des conversions in situ au chargement sur des parties de codes. 
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Les etapes du precede selon Tinvention qui viennent d'etre decrites 
dans un cadre general, vont etre illustrees plus particulierement dans ce cadre 
d'application preferee. 

Comme it est connu, une implantation du langage "Java Card" fait 
5 appel a un convertisseur qui transforme des fichiers dits "de classes" en 
fichiers "CAP", Un fichier de classe est une unite de compilation et de 
representation du code objet d'un programme "Java". Un fichier CAP regroupe 
toutes les classes d'un meme "package Java Card" et ne comporte qu'un 
unique "constant pool". Un "package Java Card" est une construction "Java" 

10 pour regrouper des classes et creer des espaces de noms. Pour sa part, un 
"constant pool" est une table associee a chaque fichier de classe pour "Java" 
et a chaque fichier "CAP" pour "Java Card". Cette table regroupe des 
constantes (chalnes de caracteres, entiers, ...). Elle est utilisee dans les 
machines virtuelles de "Java" et "Java Card". La transformation est non triviale 

15 et globale : elle remplace tous les noms (de packages, de classes, de champs, 
de methodes) par des entites appelees "tokens", c'est-a-dire des nombres 
entiers de 7 ou 8 bits. Ces "tokens" servent d'index pour acceder a des tables. 
De plus, ia transformation regroupe tous ies fichiers de classes d'un meme 
package en un fichier CAP (avec fusion des "constant pools" et reorganisation 

20 des tables de methodes). 

Le langage "Java Card" est notamment destine a etre utilise sur des 
cartes a puce bancaires. II est done imperatif de verifier la correction de la 
transformation d'un programme (ou "byte code") ecrit dans la machine virtuelle 
du langage "Java" en un programme ecrit dans la machine virtuelle du langage 

25 "Java Card", c'est-a-dire d'apporter la preuve de I'equivalence de ces deux 
programmes. 

Cette preuve formelle va etre apportee en executant ies etapes du 
procede selon I'invention. 

La premiere etape consiste en la definition d'une semantique 
30 operationneile. 

On associe a chaque instruction du "byte code" une ou plusieurs 
regies semantiques. Le "byte code" est un code assembleur portable. C'est le 
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code objet pour les machines virtuelles "Java" ou "Java Card" Par example, la 
regie semantique associee a l*une des instructions de ce code, Tinstruction 
"getfield" peut se decrire ainsi: 

5 f_ref := constant_pool (c)(/) 

(c_ref, iv) ;= h(T) 
V ;= iv(f_ref) 


("getfield /; be, r :: ops, I, c, h> => (be, v :: ops, 1, c. h) (9). 

10 

Dans Texemple, I'etat se compose du code execute avec instruction 
courante en tete (getfield /; be), d'une pile d'operandes (r :: ops) , des variables 
locales (/), d'une reference a la classe courante (c) et du tas (h). La regie 
specifie les operations effectuees lors de Texecution de getfield / : 
t5 - La fonction auxiliaire "constant^pool" utilise I'index / pour obtenir la 

reference f_ref du champ (une signature ou un "token", selon qu'il s'agit du 
code source ou transforme) dans le "constant pool" approprie. 

La reference r a Tobjet dont le champ doit etre lu est trouvee en sommet 
de pile. Cette reference permet de trouver dans le tas (h(r)) la classe 
20 dynamique de Tobjet c_ref (un nom qualifie ou une paire de tokens selon 

qu'il s'agit du code source ou transforme) et la liste des champs de I'objet 
(iv). 

En utilisant la reference precedemment calculee et la liste des champs, 
le champ est lu (v :- iv(f_ref)). 
25 - L'lnstruction getfield change I'etat en replagant la reference a I'objet par 

la valeur du champ et I'execution se poursuit avec la suite du code (be). 
La deuxieme etape consiste en la definition des types. 
Dans le cas du langage "Java Card", on definit le type Word pour 
representer Tunite de stockage : 

30 

Word = Object_ref + Null + Boolean + Byte + Short (10), 
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Comma exemple de type construit, le type d'un constant pool est : 


Constant_pool = CP_index ->CPJnf o 


(11), 


5 


avec : 


CP info = Class ref + Method ref + Field ref 


(12). 


Dans I'exemple, un "constant pool" est vu comme une fonction prenant 
un index (le type CPJndex est considere comme basique) et rendant une 
entree (ici une reference a une classe, une methode ou un champ). 

Le type du "byte code" est : 

Bytecode = Instruction + Bytecode; Bytecode 

Instruction = getfieldCP_index + Invokevirtual Cp_index + ... (13). 

Le "byte code" est une sequence d'instructions. Le type Instruction 
enumere toutes les instructions utilisees dans le "byte code" de "Java Card". 

La troisieme etape consiste en I'interpretation des types 
Dans le cas de "Java Card", I'interpretation pour le code source, sous 
la forme de fichiers de classe (qui utilise des noms), est notee [[.L^ ®^ 
['interpretation pour le code transforme sous la forme de fichiers CAP (qui 
utilise des "tokens") est notee [[.J,^^. . 

A titre d'exemple, le type [ICPjndex]]^^^^ est verifie pour le code 

source : 


[[CPJndex L = 


Class name x Index 


(14). 
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Dans le modele a base de noms, un index de "constant pool" est 
constitue d'un nom de classe (pour indiquer le "constant pool" auquel on fait 
reference) et d'un index. 

Le type [[CPJndex JJ^^j^ est verifie pour le code transforme : 


Un index de "constant pool" est constitue d'un "token" de "package" 
(dans Texemple decrit, 11 existe un "constant pool" unique par "package" ou 
10 fichier CAP) et d'un index. 

La relation Rcpjndex est definie comme une bijection telle que : (16) 

(c^namej) Rcp.index {p_tok, i') => pack_name(c_name) Rpackage_ref 

p_tok 


Le nom du "package" de la classe contenant le "constant pool" auquel 
11 est fait reference dans le modele a base de noms doit etre en relation avec le 
"token" du "package" contenant le "constant pool" auquel il est fait reference 
dans le modele a base de "tokens". La seule contrainte sur les index / et /' est 
20 que Rcpjndex doit etre une bijection (les entrees des "constant pools" peuvent 
done etre regroupees et reordonnees). 

La quatrieme etape consiste en interpretation des fonctions 
auxiliaires 


5 


[[CPJndex = Package_token x Index 


(15). 


15 


25 


Par exemple, la version de la fonction auxiliaire "constant^pool" pour 
le modete a base de noms est : 


[[constant__pool]l„^^^^ = cp_name 


(17), 


avec : 


30 


cp_name c = let (..., cp, ...) = env_name(pack_name(c))(c) 


(18). 
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in cp 

La fonction pack_name prend un nom de classe et rend un nom de 
"package" et la fonction env_nanne prend un nom de package et un nom de 
5 classe et trouve dans la hierarchie de classes la structure representant le 
fichier de classe designe. Le constant pool est extrait du fichier de classe. 

Pour le modele a base de "tokens", la version de la fonction auxiliaire 
[[const ant jpoolJJ^^jt est : 

10 [[constant_pool]],^j^. = cp_tok (19), 

avec : 

cp_tok c = let (..., cp, ...) = env_tok(p) (20). 
15 in cp 

Le "constant pool" est trouye dans renvLronnsnt (c'sst-a-dire !es 
fichiers CAP) a I'aide de la fonction env_tok et du token de package. 

La cinquieme etape consiste a prouver que les fonctions auxiliaires 
20 respectent des relations logiques. 

Si on se reporte de nouveau a Texemple de la fonction d'acces au 
"constant pool", il est necessaire de determiner que : 

[[constant_pool]]^^,^ ^cp_index CP_info [[constant_pool]l^j^ (21). 

25 

La relation Rcpjndex ^ cpjnfo est completement definie en fonction des 
relations Rcpjndex et Rcpjnfo- En se servant de cette definition, on montre qu'il 
suffit de verifier que : 

30 \/{c_name, i)(p_tok, i*) tels que {c_name, I) Rcpjndex (pjtok, i'} 

cp(i) Rcpjnfo cp'(i') (22), 
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avec : 


(..., cp, ...) = env_name(pack_name(c_name))(c_name) 
(..-, cp\ ...) = env_tok(pJok) 


(23). 


10 


15 


20 


25 


La preuve se fonde sur la definition de Rcpjnto et la propriete rappelee 
ci-dessus : (24) 

(c_name, i) Rcpjndex {pjtok, O => pack_name(c_name) Rpackage_ref p^tok 

La sixieme et derniere etape du precede consiste a determiner un 
transformateur tel que la transformation du code et des donnees par ce con- 
vertisseur respecte des relations logiques determinees. Par exemple, les 
references a des "packages" sont, soit des noms, soit des "tokens" suivant le 
modele. La relation logique associee RpBckage_ref est definie simplement comme 
une bijection entre les noms de "package" et les "tokens" de "package". II suffit 
de verifier que la fonction du convertisseur realisant la transformation des 
noms de package en "tokens" est effectivement une bijection. 

A la lecture de ce qui precede, on constate aisement que I'invention 
atteint bien les buts qu'elle s'est fixes. 

II doit etre clair cependant que ['invention n'est pas limitee aux seuls 
exemples de realisations explicitement decrits, notamment en relation avec les 
figures 2 et 3. 

Enfin, bien que le procede ait ete decrit de fafon detaillee dans le cas 
de la transformation d'un programme de la machine virtuelle du langage "Java" 
en un programme de la machine virtuelle du langage "Java Card", 
particulierement interessant pour les applications de type carte a puce ou 
similaire, Tinvention n'est en aucun cas limite a cette application particuliere. 

L' invention peut trouver application a chaque fois que le dispositif 
implique ne dispose que de ressources informatiques relativement limitees, 
notamment en ce qui concerne la capacite memoire (vive ou fixe) et/ou la 
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puissance de calcul du processeur utilise. On peut citer a titre d'exemple des 
livres electroniques, par example du type dit "e-book'\ destines a telecharger et 
stocker des donnees en provenance de sites Internet, des calculateurs de 
poche, par exemple du type dit "organiser", certains telephones mobiles 
5 pouvant etre connectes au reseau Internet, etc. Dans tous ces cas, il est 
necessaire de disposer d'un langage optimise pour utiliser au mieux les 
ressources informatiques integrees. 


01/02955 
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REVENDICATIONS 

1 . Procede de verification d'un transformateur de code dit source en un code 
dit transforme destine a un systeme embarque, lesdits codes source et 
transforme etant associes a des machines virtuelles, caracterise en ce qu'il 
comprend au moins les etapes suivantes : 

- la determination, pour chacun desdits codes source (1) et transforme 
(3), d'un premier sous-ensemble (13) commun constituant une machine 
virtuelie unique factorisant le comportement de ces deux codes (1,3); 

- la determination, pour chacun desdits codes source (1) et transforme 
(3), d'un second sous-ensemble (10, 30) constitue d'une pluralite de 
fonctions dites auxiliaires (10/ - 30,) utilisees par ladite machine 
virtuelie unique, lesdites fonctions auxiliaires (10/ - 30/) representant 
des differences residuelles entre lesdits codes source (1) et transforme 
(3); 

- I'association par paire desdites fonctions auxiliaires. une premiere 
fonction auxiliaire (10/) de chaque paire appartenant audit second 
sous-ensemble (10) associe audit code source (1) et une seconde 
fonction auxiliaire (30/) de chaque paire appartenant audit second 
sous-ensemble (30) associe audit code transforme (3) ; 

- la verification (6) d'une propriete de correspondance determinee entre 
lesdites fonctions auxiliaires de toutes lesdites paires (10/ - 30/) ; et 

- la verification que ladite transformation du code source (1) en code 
transforme (3) par ledit convertisseur (2) respecte ladite propriete de 
correspondance determinee. 

2- Procede selon la revendication 1 , caracterise en ce que ladite propriete 
de correspondance est une relation logique, de maniere a ce que lesdites 
fonctions auxiliaires de chacune desdites paires (10/ - 30/), lors de leur 
execution, generent des resultats lies par ladite relation logique, et en ce 
que cette relation est la relation identite pour des entites dites observables 
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de chacun desdits codes, source et transforme, pour touts paire de fonctions 
auxiliaires, de maniere a ce que les fonctionnalites dudit code source (1) 
soient preservees lors de ladite transformation dans ledit code transforme 
(3), et ladite verification de transformateur de code (2) reaiisee. 

3. Application du procede de verification selon I'une des revendications 1 ou 
2 a un transformateur de code (2) generant, a partir dudit code source (1) un 
code transforme (3) destine a etre enregistre dans des moyens de memoire 
(71) d'une carte a puce (7). 

4. Application selon la revendication 3, caracterise en ce que, ledit code 
transforme etant un programme ecrit dans la machine virtuelle d'un langage 
informatique determine, ladite carte a puce (7) est une carte a puce 
enregistrant une pluralite d'applications logicielles {Ay a An) ecrites dans ce 
code transforme (3). 

5. Application selon les revendications 3 ou 4, caracterise en ce que ledit 
code source (1) est un programme ecrit dans la machine virtuelle du langage 
".JAVA" (marque depcsse) st Isdit coda transfoime (5) est un programme 
ecrit dans la machine virtuelle du langage "JAVA CARD" (marque deposee). 
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LISP" 

IEEE TRANSACTIONS ON SOFTWARE 

ENGINEERING, US, IEEE INC. NEW YORK, 

vol. 23, no. 4, 1 April 1997 (1997-04-01), 

pages 203-213, XP000720014 

ISSN: 0098-5589 

the whole document 

FR 2 757 970 A (GEMPLUS CARD INT) 
3 July 1998 (1998-07-03) 
claims 1,6,7 
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1,2 


1,4 
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Further documents are listed in the continuation of box C. 
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"A* document defining the general state of the art which is not 
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*E' earlier document but published on or after the international 

filing date 
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which is cited to establish the publication date of another 
citation or other special reason (as specified) 

'O" document referring to an oral disclosure, use, exhibition or 
other means 

■P' document published prior to the international filing date but 
later than the priority date claimed 


"T* later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" docuffnent of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevarTce; the claimed invention 

cannot t>e considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such comt>ination being obvious to a person skilled 
in the art. 

'&■ document member of the same patent family 


Date of the actual completion of the international search 


1 September 2000 


Date of mailing of the international search report 
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European Patent Office, P.B. 5818 Patentlaan 2 
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Fax: (+31-70) 340-3016 


Authorized officer 


Kingma, Y 
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ALBERDA M I ET AL: "Using formal methods 
to cultivate trust in smart card operating 
systems" 

FUTURE GENERATIONS COMPUTER 

SYSTEMS, NL, ELSEVIER SCIENCE PUBLISHERS. 

AMSTERDAM, 

vol. 13, no. 1, 1 July 1997 (1997-07-01), 
pages 39-54, XP004081708 
ISSN: 0167-739X 

page 53, left-hand column, line 2 - line 
33 

abstract 


1-4 


Fomrt PCT/ISA/210 (continuation at second sheet) (July 1992) 


page 2 of 2 


INTEIj^TIONAL SEARCH REPORT 

Imormatlon on patent family members 


Imerna 


al Application No 

PCT/FR 00/01815 


Patent document 
cited in search report 


Publication 
date 


Patent family 
memt3er(s) 


Publication 
date 


FR 2757970 


03-07-1998 


AU 
CN 
EP 
WO 


5769598 A 
1247609 A 
1012710 A 
9829803 A 


31-07-1998 
15-03-2000 
28-06-2000 
09-07-1998 


Form PCT/ISA/210 (patont family annex) (JLdy 1992) 


TRAITE D 


w 


POPERATION EN MATIERE DE, 

PCT 


w 


VETS 


RAPPORT DE RECHERCHE INTERNATIONALE 
(article 18 et regies 43 et 44 du PCT) 


Reference du dossier du ddposant ou 
du mandataire 

JL/B51856 

POUR SUITE ^^''* notification de transmission du rapport de recherche intemationale 
(formulaire PCT/ISA/220) et, le cas echdant, le point 5 ci-apr6s 

A DONNER 

Demande Internationale n° 
PCT/FR 00/01815 

Date du ddpot international ^our/mo/s/annee^ 

28/06/2000 

(Date de priorite (la plus ancienne) 
(jour/mois/annee) 

01/07/1999 

Oeposant 

BULL CPS 


Le present rap)port de recherche intemationale, etabli par 1' administration chargee de la recherche intemationale, est transmis au 
deposant conformement a I'article 18. Une copie en est transmise au Bureau international. 

Ce rapport de recherche intemationale comprend 3 feuilles, 

[T] II est aussi accompagne d'une copie de chaque document relatif a Tetat de la technique qui y est cite. 


1. Base du rapport 

a. En ce qui concerne la langue, la recherche Internationale a ete effectuee sur la base de la demande Internationale dans la 
langue dans laquelle elle a ete deposee, sauf indication contraire donnee sous le meme point. 

I I la recherche Internationale a ete effectuee sur la base d'une traduction de la demande intemationale remise a Tadministration. 

b. En ce qui concerne les sequences de nucleotides ou d'acldes amines divulguees dans la demande intemationale (le cas echearrt), 
la recherche intemationale a ete effectuee sur la base du listage des sequences : 
I I ' contenu dans la demande intemationale, sous forme ecrite. 

deposee avec la demande Internationale, sous forme dechiffrable par ordinateur. 


2. 
3- 
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rem is utterieuremeht.a Tadministration, sous forme ecrite. 

remis ulterieuremeht a radministration, sous forme dechiffrable par ordinateur. 

La declaration, seloh laquelle le liistage des sequences presente par dcrit et fourni ulterieurement ne vas pas au-dela de la 
divulgation faite dans ia demande telle que deposee, a ete fournie. 

La declaration, selon laquelle les informations enregistrees sous forme dechiffrable par ordinateur sorrt identiques a celles 
du tistage des sequences presente par ecrrt, a 6te fournie. 

II a ^t^ estlme que certalnes r^vendlcatlons ne pouvalent pas faire I'objet d'une recherche (voir le cadre I). 
II y a absence d'unlt^ de I'tnventlon (voir le cadre II). 


4. En ce qui concerne le titre, 

pT] le texte est approuve tel qu'il a ete remis par le deposant. 

[ I Le texte a 6X6 etabli par t'administration et a la teneur suivante: 


5. En ce qui concerne I'abr^g^, 

le texte est approuve tel quMI a etd remis par le deposant 
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le texte (reproduit dans le cadre III) a ete etabli par radministration conformement a la regie 38.2b). Le deposant peut 
presenter des observations a radministration dans un delai d'un mols ^ compter de la date d*expedition du present rapport 
de recherche intemationale. 


6. La figure des desslns a publier avec I'abrege est la Figure n** 


Pn suggeree par le deposant. Q Aucune des figures 

I I parce que le deposant n'a pas suggere de figure. ^ ^ publier. 

I I parce que cette figure caracterise mieux T invention. 
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Documentation minlmale consults (syst^me de dassiftcation suivi des sym botes de classement) 

CIB 7 G06F G06N 


Documentation consult^e autre que la documentation minlmale dans la mesure ou ces documents reinvent des domaines sur tesquels a portd la recherche 


Base de donndes diectronique consults au cours de la recherche intemationale (nom de la base de dortn^es, et si realisable, termes de recherche utilises) 

EPO-Internal , INSPEC, RAJ 
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Categorie * Identification des documents cites, avec, le cas ech^ant, {'indication des passages pertinents 


no. des revendications visees 


KAUFMANN M ET AL: "AN INDUSTRIAL STRENGTH 
THEOREM PROVER FOR A LOGIC BASED ON COMMON 
LISP" 

IEEE TRANSACTIONS ON SOFTWARE 

ENGINEERING, US, IEEE INC. NEW YORK, 

vol. 23, no. 4, 1 avril 1997 (1997-04-01), 

pages 203-213, XP000720014 

ISSN: 0098-5589 

le document en entier 

FR 2 757 970 A (GEMPLUS CARD INT) 
3 juillet 1998 (1998-07-03) 
revendications 1,6,7 
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Les documents de families de brevets sont indiqu6s en annexe 


" Categories sp^ciales de documents cit^s: 

'A' document ddfinlssant I'dtat g6n6ral de la technique, non 
consid6r6 com me particulierement pertinent 

'E" document ant^rieur. mais publid a la date de ddpdt international 
ou apr^ cette date 

"L" document pouvant jeter un doute sur une revendication de 
priority ou cite pour determiner la date de publication d'une 
autre citation ou pour une raison sp^ciale (telle qu'lndlquee) 

'O' document se r^f^rant ^ une divulgation orale. d un usage. ^ 
une exposition ou tous autres moyens 

■P' document publid avant la date de d6p6t International, mais 
post6rieurement a la date de priority revendiqu^e 


document ultdrieur public aprds la date de ddpdt intemational ou la 
date de priority et n'appartenenant pas ^ I'dtat de la 
technique pertinent, mais cit6 pour comprendre le principe 
ou la thdoHe constituant la t>ase de {'invention 

document particulierement pertinent; I'inven tion revendiqude ne peut 
etre considdree comme nouvelle ou comme impli quant une activite 
inventive par rapport au document consider6 isoi6ment 

document particulierement pertinent; I'inven tion revendiquee 
ne peut etre consideree comme impliquant une activite inventive 
lorsque le document est associe e un ou plusieurs autres 
documents de mSme nature, cette combinaison 6tant evidente 
pour une personne du metier 

document qui fait partie de la mdme f ami He de brevets 


Date a laquelle la recherche intemationale a ete effectivement achevee 


1 septembre 2000 


Date d' expedition du present rapport de recherche intemationale 


08/09/2000 


Nom et adresse postale de {'administration chargee de la recherche intern ationaie 
Office Europeen des Brevets, P.B. 5818 Patentiaan 2 
NL-2280 HV Rijswijk 
Te{. (+31-70) 340-2040, Tx. 31 661 epo nl, 
Fax: (+31-70) 34CK3016 


Fonctionnaire autorise 


Kingma, Y 
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TRAIi^DC COOPERATION EN MATI[^p:>E BREVETS 

Exfsediteur: le BUREAU INTFRNATIONAI 


it 36/ 27 


PCT 

NOTIFICATION DE LA RECEPTION DE 
LEXEMPLAIRE ORIGINAL 

(regie PCT) 


Doctinataifo: 


ROGER PETIT. Cjeorges 
Office Bletiy 

2, boulevard d© Strasbourg 
F-750IO Paris 

rnANCc 


Date d'expedttion (jour/mois/annee) 
29 aoOl 2000 (29.08.00) 

Reference du doaaicr du ddpoaom ou du mondotoirc 

JLyBS1856 


NOTIPICATION IMPORTANTE 


Dcmandc irrtcrnotionalc no 

PCTyFROO/01815 


It cat notifi6 iau d6posont que Ic Durcoiu inicrnational a rc^u I'cxcmploirc original dc la dcmondo Intcrnotlonale prcci^oe 
ci-3pres. 

Nom(3) du ou dc3 d£po3Qnt3 cl dc I'Etot ou dcs Eiato pour Icaqucis il3 3ont dcpoaanto: 

BULL CPS 9tc. (pour tous les Etats designee sauf US) 
GOIRE, Christian etc. (pour US seulennem) 

uato du dfiipot (ntornattonal : 28 Juin 2000 (28,06.00) 

Dotc(3) dc pnoritA rovondiqu66(3) : 01 julllet 1999 (01.07.99) 

Date de r^ceoiion do I'oxemolaire original 
p;»r Ift Riirft.iM inmrnarinn:>l : 

Listo dGS offices ddsignds : 


02 aofit 2nnn (n2.n?;::co) 


EP :AT,BE,CKCY,DE,DK,ES,FI,FR,GB,GR,IE,IT,LUMaNL,PT,SE 
Nailonal :BR,CA,CfM,JP,US 


ATTENTION 

Lc d£po3Qnt doit aoignouscmcnt verifier Ic3 indicotiono figurant don3 la priacntc notifiootion. En ooo dc divorgo^oc ontrc oc3 
Inoicailons er cefles que contleni la demanae imernatlonale, li doit aviser imm6dtatement le Bureau international. 

Ell uutfc, rallmiition du dfiposaiil c:;t uppcl^c :»ui Ics icrr.ici(jiiciricnLs Uunii(;:> dans raiiticAc en cc qui i;uuwct nc 


tes delate dans lesquels dott erre abordee I? phese nationale 
I X[ l8 confirmation oes designations feites par mesure de precaution 

I I Ic3 cxigcnoc3 rclotivca aux dooumcnts do pfiorltc. 


Une coDie de (a Dr6sente notification est envov6e ^ Toffice rfeceoteur ei a radministration chargee de la recherche internationale. 


Buroau intornational de I'OMPI 

Fonctionnair© au!ori36 n\Js^ 



Philippe Became! i ^^L^' 

1211 Geneve 20, Suisse 

n" detelecooieur (41-22) 740.14.35 

n* de teieohone (41 -221 338.83-38 \ 


Formulaire PCT/IB/301 fiuiilet 1998) 
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f nr.mnnrlft inTftrnntton^ile no 

Ar^N^ ^U FORMUIAIRE PCT/IB/301 ^^^^ PCT/FRUO/0181 b 


RENSEIGNEMENTS CONCERNANT LES OELAIS DANS LESQUELS DOIT ETRE ADORDCC 

LA PHASE NATIONALE 


II est rappelo au deposant qu'il doit aborder I9 "phas© national©" aupris d© chacun dcs offices desicjnes indicjU^S ^t.tr I? 

iploifc uiiyiMdl (foiit»uldi»c PCT/IB/301) en poyont IwS laxos nationoica ct cn romortont Ics 
traductions, relies au'elles'sont prescrites oar les legislations nationales- 

P 

Le delaf d'accomplissement de ces ectes de procedure est de 90 MOIS J comptor d«lp HaTo rie prinrite on, pour les ttats 
dcsigncs qui ont 616 6iu3 per Ic depose nt dons unc dcmonde d'oxamen prcHminaire intornationol ou dona unc election ultcricurc, 

ce 30 MUlii a compter de la date de priorite, e condition que cette eleaionait eie effectu6e avani roxpiraiion du I9e mois 
r.nmptftr rift la rifltft rip. prinritA. Cftrtains nffires rier.iones (ou ftliis) ont fixe Hfis delais qui ©xoirent au*de[^ de 20 ou 30 mois a 
compter do lo doto do prioritd. D*autrc3 offioc3 oooordcnt unc prolongation dca dc'ois ou un d6bi do grace, dene cortaing cae 
moyennant le palemeni d'unetaxe suppi6menralre. 

En plus de ces actes de orocedure, le ddoosant devra dans certains cas satisfaire t d'autres exigences p3n(cui(6res 
applicables dsns certains offlcos. (1 appartiont au deposant d© voillor i rompllr on temps voulu les conditions roriiiisoR pniir 
I'ouvoHuic do Id pltciio iitf tiotidle. La majoritw des offices dfisign6s n'onvoicnt pas dc rappcl 0 I'cpproche de la dato limitc pour 
aborder la phase national©. 

' Dftic infnrmATinn<t ri^aill^Rj; mnrf^mjinr \ftR satea. de prnoedure a accompli r pour aborddf la ohasc nationale aUDreS de 
chaquc office d£3ign6, lea dcloio oppliooblcs ct la possibilrto d'obtonir uno prolongation doc d6l3ic ou un delai de grSe© ©ttoutsc 
autres condUons appllcabtes flgurent dans le volume II du Guide du dfippsant du PCT. Lus cAit^ciiccs cuitwrmdnl le d«pfit d'unc 
demdnde d*exannen oritimmaire international sont expos^es dans lo chaprrro IX du volume I du Guide du deposant du KCI. 

GRot ES fiontdovenues ti^es par le chapitre II du PCT Ie7 septembre 1S96 et le 6 septembro1997. rp.spfirTivftmfint, et 
pcuvcnt done Atrc 6luc5 dans unc dcmandc d'cAomcn prcllmlnelre international ou dans une 6loction ultdricuro prcsontoc Ic 7 
septembre 1896 (ou a une date posterleure) ou le 6 septembre 1997 (ou a une date postdrloure). respeCTivemem, quelle que soit 
la date de depot de la demande Internationale (voir le second oaragrapho. ci-dessus). 

Veuill63 noier que ceul un d4po&ant qui ect ressortiscant d'un Etat contracts nt du PCT Ii6 par lo chapitre II ou qui y ? 
SUM Juiriicilc pcul preset >ie'i utic Uoincn'tJc d'cXeniidn pi Qlini!naii'6 inxetnatiCfiial. 

CONFIRMATION DES DES I Ci NATIONS HAH fcS PAR MbSUKt Dt PRECAUTION 

Seules les designations expresses taites dans la requsto conTormem.ent a la r6gie 4.y.a) figurent dans la presente 
nofifirafinn. II oct impotanT ein vAn'fiftr !tl res rlAsipnatinns nnT fsitfts r'orr^cTemRnT. Dbs erreurs dans les d^sionations peuvdnt 
6trc corrig6c3 ioraquc dco diofgnotiono ont ^t6 faitco por mcourc do prcooutton cn vcrtu do la riglo "I.O.b). Toute designBtion 
alnsl fa tie peut fitre conflrm6e conformSment aux dispositions de la regie <i.9.c) avant rexpiratiun d'un Uclai Jo 15 mois d 
comoter de la date de oriorite. En I'absence de conf rmaiion. uno d6siqnation faite par mesure de precaution sera consid6r6e 
eommo r©tir6o par I© deposant. H no sera adress4 aucun rappel ni invitation. Pour confirmer une de?iO'^^^''^n , il f.-^tiT W^pnsftr iinA 
declaration pr6eisani I'Ctat d6sign6 conccrn6 (avcc I'indicotion dc lo forme dc protection ou do troitement 3ouhQit6e) ct payer Ic3 
taxes ae a6s(gnation ei de confirmation. La confirmation doit parvenir 9 I'cffice recepieur cans le d6ial de 16 mois. 


EXIGENCES RELATIVES AUX DOCUMENTS DE PRIORITE 

Poi.ir Iflii d«po?ant<; nuf n'nnr pac p.nr.nrd sflTisf.'^ir anx Rxigftnres rp.I.iTfyfts aux dnciiments de oriorit6. it est raDpel6 ce QUI 

3uit. 

Lorsque la prJorlifi d'une demande nailonaie, r6gionale ou internaiionale ani6rieuro osi icvcjiJiquec, Ic doposam doit 
presenter une cooie de cette demande anterieure, certifi^e conforme oar radministration aupr6s de laquelle elle a 6t6 deposee 
("document de priorite"), a I'otfic© r©c©pt©ur (qui la trantmettra au Buraau international) ou directement au Ri.iroaii inrornationpl. 
ovaiU rcApiioliuri d'un Uclai dc 10 mofi a conipttsr de la date de priority, wtant ontendu que tout document do prioritfi peut Stre 
presente eu Bureau international avant la date de pubncation do la demande Internationale, auquei cas ce document sera repute 

avoir ete reju par lo Rureau Intern^tionpl Ip Harnlftr jrmr rlii d^lni rto Ifi mnis (rAg(ft 17.1. a)). 

Loraquo la document de priorii6 cat d6livr6 por I'officc r6ocptcur, Ic dcpoaont peut, au lieu do pr6contor oe document, 
demander a I'offlce recepteur de lo preparer et de le transmenre au Bureau international. La requQte d cbi offci duii ctic 
formulae avant I'exDiralion du d6lai de 16 mois et peut etre soumise au baiement d'une taxe (r^ale 17.1.6)). 

Si le dooumonr de priorttfi en quection n'eet poe ^ourni au Sureau international, ou £t la domandc adress^e a ro^fice rocepteur 
dc pi6paicr cl du UdrisiticLuo lo Uucuiiicnl dc piiuf ilc 11*0 ^aa clc failc (cl la laXc uui 1 capondante acquittic, Ic caa ccheont) 
avant I'expiratlon du d6lai aoolicable meniionne aux paragraphes precedents, tout Etat designe peut ne pas tenir compte 
do la revendioation do prIorii6; toutefois, aucun office desione ne peut decider de ne pas tenir co"^PTo do h revRnHiofltion dn 
prioriti avant d'avoir donn6 au diposant ta possibilite dc rcmcttrc Ic document dc prioriic danj un d6Iai rotsonnobic cn I'copficc. 

Lorsque plusieurs pnorites sont revendiquees. la date de priorite a prendre en consideration aux Tins au calcui du ddiai de 
1 R moir. rst rlnir* rlii rf^pAf dp. Ifl rlftmanrle Ifj pluR AnniftnnR riont la priorite e.st rev/findiau6e. 


Pormulairo PCT/IO;301 (annexe) (iuillet 1993} 
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(regl© AlA.c)^ premidre phrace, du PCT) 

Destinatsire: 

ROGER PETIT, Georges 

Office Bletry 

04, rue Saint Lazare 

F-76010 Paris 

FRANCE 

Odte dVxveOUiuii (juui/iMuis/atiiicc) 

11 janYier2001 {iV.Ol.OI) 


JL/B5185b* 

AVIS IMPORTANT 

Dctiiundc inlcindtionale no 

rCT/rROO/01815 

Date du d6p&i International Qour/mols/ann6e) 
20 juin 2000 (20.00.00) 

Date dc prior ru^ your/mols/annt^o) 
01 juillet 1999 (01.07.99) 

BULL CPS etc 


1. II est notifi6 par la pr6t6nt» qu's la dsto !ndiquee ci-deecuc comme date d'exp4dition de oet ^vic. Id Bureau international 3 
oonnmuniquo, oommc Ic prcvoit I'ortiolc 20, Id dcmondc intcrnotionale aux offices dfiaign^s auivantj: 

us 

CnnfnrmAmftnT k U rA.glft 47.1 r). trniciimA phrpeio, offices scceptent io present svis comme preuve d^terminante 
du fait que la communication do is d^msnd^ Internationals a bten eu Mdu oi la date d'exp^ditton indiqu^e pluc haut, et la 
d6potant n'oct p3C tcnu dcircmcttrc dc oopic dc la dcmondc intcrnotionolc h I'officc ou aux offices d^aignSa. 

2. Lea uffiuca dcbiyiics suivciils uriUcjionu6 k roAiycrtco selon laqueMe cene communication CoU &tre effeciufee 5 cette date: 

BR,CA,CN,EP,JP 

La communication sca effecTu6e seuiement sur demande de ces omces. Do plus, Ig ddposant n'est pas tenu de remenrG 
de copie de la demande internationaie aux onices en quostion (r6gle dy.lja-bi5)). 

3. Ic present ovis cit accompa^n^ d'uno copie de la demande inlon'tdlloiialc publlee pdi Ic Buicau iiilcinaliunal Itr 
n jonvicr2001 (11.01.01) sous le numero WO 01/029S5 

RAPPEL CONCERNANT LE CHAPITRE II (aaicle 31.2)a) el regie 54.2) 

3i lo UcpOdai'L duulioite icfjurlci Tuuvci luic Uc la phasic iiatiurialu ju:jqu'd 30 tnuis (uu plus pour ce qui concerne cunains 

offices) d compier de la oate de priorli6, ta dcmande d'examen preit'minaire inrrernationdl doii etre presentee a 
I'aanninistration compdtente charg^e de I'examen preiiminaire international avant rexptrarion d'un d6(ai de 19 mois 3 
comoter de la date de oriorite. 

il dppciiliciil cAulu^i/ciMciU au depu^aiil dc vcillci au ic:>pct'l du d6lBi du 19 rnois. 

11 est e noter que seul un d^posant qui est rocsortiscant d'un Etat contraetant du PCT lig par le chapitre M ou qui y a son 
dorhioile peut pf6contor uno demand© d'o«omen prcliminoirc international. 

RAPPEL CONCERNANT L'OUVERTURE DE LA PHASE NA TlONALt (article 22 ou 33.1)) 

i>i le deposant souhaite que la demande internationaie oroc^dc en phase nationale, il doit, dans le d4lat de 20 mois ou 
de 30 nnois. ou oius pour co oui concerne certains offices, accomnltr Irs acres menttonnfts Han?: r.fts fiisposirinns flupre?: 
e^tu ch^nuo office desio"^ ^l'-'- 

Pour d'auires informations importantes conccrnant los ddiais et ie& actes a accompiir pour I'ouverture de la phase 
nationalG. voir ('annexe du formulaire PCT/IB/301 (Notification de la reception de TexenriDlajre original) et le volume II 
dti GrjiHe du deposnnr Hti PCT. 


6uicju MilcrfiaUunal du I'DMPI 

^onctionnaire autorise 


34, chcmin des Colombettes 

J. Zahra 

1211 Gon«vo 20, Suisse 


no do t6l6oopiour (41 22) 740.14-35 

no dc t£l6phonG (41-22) 33S.S3.3S 

Formulaire PCT/IB.'30S (juillot 1066) 

3752207 
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